Subject: Comments to cpiccut2

From: [email-masked]
Date: Fri, 26 Aug 94 09:19:50 +0100

Here are some comments to Jeff's new proposal for mapped conversations 
(file cpiccut2.ps)

Sorry, Jeff, there are still a lot of typos in your document.
It was not easy to review.

- p.2:  In the last line, it should be Page 42 instead of Page 33.

- p.3:  Change CMRMVX to CMRMDX in the 5th paragraph.

- p.3:  I'd like to change CMRCM to CMRCVM througout the whole document.
	So the new calls CMRCVM/CMSNDM are similiar to CMRCVX/CMSNDX.

- p.3:  A new call CMSJT was created by X/Open with the call number 75.
	So we have to change the call numbers CM_CMEMID ... to the
	values 76-81. Same changes in the C pseudonym file.

- p.4:  The control_information values are not consistent througout the
	document:
		CM_EXPEDITED_MAPPED_DATA
		CM_EXPEDITED_MAPPED_DATA_AVAIL
		CM_EXPEDITED_MAPPED_DATA_AVAILABLE
		CM_EXPEDITED_MAPPEDDATA_AVAILABLE

- p.4:  The new control_information value CM_RTS_RCVD_AND_EXP_MAP_DATA_AVAIL
	is missing. Numeric values are missing.

- p.4:  This page describes two different return codes
	CM_UNKNOWN_MAP_NAME_REQUESTED
	CM_UNKNOWN_MAP_NAME_RECEIVED 
	The rest of the document uses the return code
	CM_UNKNOWN_MAP_NAME 

- p.4:  The return code CM_MAP_ROUTINE_ABORT is sometimes called
	CM_MAP_ROUTINE_ERROR.

- p.4:  Return codes > 100 are reserved for sync point errors.
	Change the new return code numbers to the values 50-52.
	Same changes in the C pseudonym file.

- p.5:  I cannot find any situations in which a CPI-C call does return
	CM_PROGRAM_PARAMETER_CHECK with one the secondary return codes
	209, 210, 211.

- p.5:  Change
		{dr, no, mp}
	to
		[ok,mp] {dr,no}

- p.5:  The proposed change to Page 377 indicates that a return_code
	value of CM_UNKNOWN_MAP_NAME leads to Reset state. Is this really
	true?

- p.6:  The following defines are missing:
		#define Send_Mapped_Expedited_Data      cmsmdx
		...

- p.6:  New control_information values are missing.

- p.8:  Changes to non C pseudonym files are missing.

- p.9:  Appendix D describes on severel places that CPI-C does not
	support MAP_NAME. We have to change this.

- p.17: Change RCVMAP to CMRCM several times.

- p.24-60: The description of the new calls contains a lot of text
	of the original calls (Send_Data, Receive, etc.).
	But there are a lot of small differences which seem erroneus to me.
	The document would be easier to review if it would contain
	only the differences between the new and the original call.

	It seems to me, that your page numbers do not refer to the
	final CIW document. So it would be possible that you copied
	the errors contained in your preliminary document to your
	proposal.

- p.25: We need an additional control_information_received value:
	CM_RTS_RCVD_AND_EXP_MAP_DATA_AVAIL

- p.25: We have to complete note 2 with the new values.

- p.25: The return code CM_OPERATION_INCOMPLETE is missing.
	Jeff has refused this change in the last review, but in my
	CPI-C document the Send_Expedited_Data call allows this
	return code. So it may be an error in Jeff's preliminary
	CPI-C document.

- p.25: The second reason of CM_PROGRAM_PARAMETER_CHECK is missing
	in the list of secondary return codes.

- p.28: The description of the map_name parameter still contains
	'integer value'. The description of map_name_length is missing.

- p.28: We have a problem on the requested_lenght parameter:
	LU6.2 does not allow expedited data longer than 86 bytes.
	But after conversion data may be longer. So we should not
	restrict requested_length to 86.

- p.29: We need an additional control_information_received value:
	CM_RTS_RCVD_AND_EXP_MAP_DATA_AVAIL

- p.29: We have to complete note 2 with the new values.

- p.30: The return code CM_OPERATION_INCOMPLETE is missing.

- p.30: Error in lines 6/7: send_length is not part of this call.
	See the above note to the requested_lenght parameter.

- p.30: Which return code should occur when the map name is unknown?
	a) CM_PROGRAM_PARAMETER_CHECK (The map_name is unknown).
	b) CM_UNKNOWN_MAP_NAME.

- p.31: Change 'receive_length' to 'received_length'.

- p.34: The description of the status_received values
		CM_TAKE_COMMIT_DATA_OK
		CM_TAKE_COMMIT_SEND_DATA_OK
		CM_TAKE_COMMIT_DEALLOC_DATA_OK
	is much shorter than in the Receive call.
	I do not see any reason for this.

- p.35: I think we need additional control_information_received values:
		CM_ALLOCATE_CONFIRMED_WITH_MAPPED_DATA
		CM_ALLOCATE_REJECTED_WITH_MAPPED_DATA
	The same is valid on the Send_Mapped_Data call.

- p.35: The control_information_received value
		CM_ALLOCATE_REJECTED_WITH_DATA
	is missing.

- p.36: We have to complete note 2 with the new values.

- p.43: The usage note 10 of the original Receive call is missing.
	(I think, it is not contained in Jeff's preliminary document.)

- p.44: Change 'receive_length' to 'received_length'.

- p.46: The descripton of the buffer parameter should be behind the
	description of map_name_length.

- p.48: We have to complete note 2 with the new values.

- p.56: According to Jeff's last mail, OSI TP profiles require a
	receiver to to accept 0 - 10000 octets. After the work of the
	map routine the length of the initialization data may be
	bigger than 10000 bytes. So we cannot restrict initialization_data
	to 10000 bytes. If the CPI-C user sets requested_length=10000
	it may happen, that he gets the return code CM_BUFFER_TOO_SMALL.
	We should describe this in an additional usage note.

- p.60: Usage note 5 is erroneous:
	- send_length is not part of this call.
	- The note should not be restricted to LU6.2 CRM.

- p.60: I'd like to add an additional usage note:

	Because of the work of the local map routine the real amount
	of data that is sent by the CRM may be bigger than 10000 bytes,
	even if initialization_data_length is less than 10000.
	In this case the remote system may not be able to read the data.
	So the maximum value of initialization_data_length depends
	on the map routine and the abilities of the remote system.

Additional points:

- I think, we should update the figure 2 on p. 13 of the CPIC book
  (Operating Environment). The mapping routine should appear in this
  figure.

- The Extract_Maximum_Buffer_Size call refers to the Receive and 
  Send_Data calls. It should also refer to the Receive_Mapped_Data and
  Send_Mapped_Data calls.

  It may be possible, that there are additional references of the
  Receive and Send_Data calls, which also have to be updated.

- The glossary should contain some information about
  - map routine  
  - U-ASE
  - ASN.1

Peter Binninger

-----------------------------------------------------------------------------
Peter Binninger                         Voice: (+49) 7531-87-4758
Computer Gesellschaft Konstanz mbH      Fax:   (+49) 7531-87-4888
(Siemens Nixdorf Informationssysteme)   Email: [email-masked]
Max-Stromeyer-Strasse 116
78467 Konstanz
Germany